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REMARKS 

Applicant respectfully requests reconsideration and allowance of all pending claims in view of 
the above-amendments and the following remarks. 

I. CLAIM REJECTIONS UNDER §101 

Claim 23 was rejected under 35 U.S.C. §101 as being allegedly directed to unpatentable 
subject matter. 

With this Amendment, claim 23 is cancelled without prejudice. 

H. CLAIM REJECTIONS UNDER §1 12 

A. §112, First Paragraph 

Claims 21 and 22 were rejected under § 1 12, para. 1, as being "single means" claims. 
Claims 21 and 22 are amended to include elements of independent claim 1 and are reformatted 
slightly to more clearly define subject matter that is more than a "single means". 

B. §112, Second Paragraph 

Claims 1-22 were rejected under §112, para. 2, as being indefinite regarding the phrase "API- 
type source functions". 

Accordingly, claims 1 and 20 are amended to replace this phrase with, "API-type source 
functions" as suggested by the Examiner. 

Also, various claims are amended to remove optional parenthetic phrases. 

m. CLAIM REJECTIONS UNDER § 102(b) 

Claims 1-3, 8, and 11-23 were rejected as being allegedly anticipated by Andy , " Integrating 
monitoring and telemetry devices as part of enterprise information resources ," XP-002283767 
(March 2002) (hereinafter referred to as the "IBM Document"). 

A. IBM document 

1.1 Summary of the document 

The IBM document concerns a general protocol for MQ Integrator SCADA device (usually 
named MQIsdp) developed by the IBM Software Group. It deals with notions of "publish" and 
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"subscribe", and illustrates some examples of application. 
1.2 Relevance of the document 
In accordance with the Examiner's opinion, the IBM document discloses (using the terms of 
Applicant's claim 1): 

System for remote control of apparatuses (« a system that manages the flow of information 
from remote devices to any enterprise applications that need the data », p. 3, 1.1-3, 
« telemetry integration applications », p.9, 1.8), enabling the interconnection between at least 
one broker ( « broker » ) and at least one remote apparatus ( « client » ) according to the 
MQIsdp protocol ( « this allows remote devices to connect to the broker using the MQIsdp 
protocol », p.9, 1.2-3), it associates, with at least one of said remote apparatuses, 
radiocommunication means (« the devices communicate with the Arcom Director unit using 
20-mile line-of-sight, spread-spectrum wireless links from Data-Line Goup », p. 12, 1.3-4, 
« communicating through Very Small Aperture Terminal (VSAT) satellite links », p. 13, 1.3); 

API-type source functions enabling at least one application to be embedded ( « the 

application programming interface (API) presented to applications on the client device », p. 
9, I. 15-17). 

1.2.2 Contrary to the Examiner's opinion, the IBM document does not disclose 
(using the terms of Applicant's claim 1): 



radiocommunication means capable of internally processing a communication 
protocol implementing API source functions available in a software platform (e.g., 
Open AT) enabling at least one application to be embedded; 

radiocommunication means are provided with a set of specific (API) functions 
enabling data to be exchanged with at least one server implementing said MQIsdp 
protocol, so as to enable an interconnection between said broker(s) and said remote 
apparatus(es) via said radiocommunication means, with the latter also managing at 
least one application between said broker(s) and said remote apparatus(es). 

The Examiner raises the following extract (page 9, lines 15-17) of the IBM document: « The 
MQIsdp protocol specification is deliberately non prescriptive regarding the application 
programming interface (API) presented to applications on the client device. » 

It seems that the Office Action does not apply the IBM document correctly to Applicant's 
claim 1. This phrase means that the protocol does not describe means of using an application 
programming interface of the terminal in itself . Indeed, as a general principle, remote terminals 
comprise in their own integrated equipment (microprocessor, memory cards, etc..) a library of 
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functions to enable the terminal to understand instructions received by the broker according to the 
MQIsdp protocol. API functions are thus specific for each application of each terminal and are an 
integral part of the terminal which shall necessarily have a hardware architecture and software 
architecture so as to work according to the MQIsdp protocol . 

The above-mentioned extract seems to suggest that this specification of MQIsdp protocol 
does not detail the set of API functions (whose the existence is evident) since they depend on each 
specific application of the terminal (or the "client"). 

As a consequence, this extract is not relevant towards claim 1, and furthermore this 
constraining feature is part of the aspects that the one or more embodiments of the present 
invention tries to improve. 

As a matter of fact, an embodiment of the present invention is characterized by the fact that 
the set of API functions is integrated in an independent module (or more generally in means of 
radiocommunication such as described in claim 1) performing the interconnection between the 
remote terminal ( does not need to know the MQIsdp protocol ) and the broker sending messages 
according to this MQIsdp protocol. Thanks to this independent module, the remote terminal 
(regularly limited in terms of resources and power) is no longer constrained to integrate a software 
architecture (for instance a telemetry architecture) and the corresponding protocol (MQIdsp), these 
functions being taken in hand by the module according to the present application. 

Furthermore, the expressions used in claim 1, such as "platform" or "interconnection 
between at least one broker and at least one remote apparatus", show that the above-meantioned 
means of radiocommunication specify a physical element, and more particularly a module which is 
external and associated to the remote equipment. To clarify this point, independent claims 1 and 
20-22 are amended to specify the rediocommunication means is "external" to the remote 
apparatus. 

As a consequence and contrary to the Examiner's opinion, the IBM document is not relevant 
toward the invention as defined by independent claim 1 of the present patent application. 



IV. CLAIM REJECTION UNDER § 103(a) 

Claims 4-7, 9 and 10 were rejected as being allegedly unpatentable over the IBM document 
in view of Petite U.S. Patent No. 7,103,511. 
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A. PETITE document : (U.S. 7,103,511 B2) 

2.1 Summary of the document 

The PETITE document deals with wireless communications networks for remote controlling 
and monitoring wireless devices. More particularly, this document concerns an automatic control 
system for controlling remote equipment implemented via a host computer, which is connected to a 
wide area network 120 (WAN) and comprising a plurality of wireless transceiver devices 125. Each 
transceiver device 125 has a unique identifier and means of: 

- receiving a sensor data signal from one of remote devices; 

- transmitting an original data message using a predefined wireless communication protocol 

comprising the corresponding unique identifier of device 125 and sensor data signal. 
One of the plurality of transceiver devices 125 is in charge of sending the whole original data 
messages to an site controller 150, connected to the WAN 120, which is configured to manage 
communications between wireless communications networks (remote equipments) and the host 
computer connected to the WAN 120. 

2.2 Relevance of the document 

Even though the PETITE document treats of a system for monitoring and/or controlling a 
plurality of remote devices, there is nothing in PETITE that discloses or suggests any of the 
inventive features of claim 1, namely (using the terms of Applicant's claim 1): 



- the fact that the system for remote control of apparatuses enables the interconnection 

between at least one broker and at least one remote apparatus according to the 
MQIsdp protocol; 

- the fact that the system associates radiocommunication means capable of internally 

processing a communication protocol implementing API-type source functions 
available in a software platform (Open AT) enabling at least one application to be 
embedded ; 

- the fact that said radiocommunication means are provided with a set of specific (API) 

functions enabling data to be exchanged with at least one server implementing said 
MQIsdp protocol, so as to enable an interconnection between said broker(s) and said 
remote apparatus(es) via said radiocommunication means, with the latter also 
managing at least one application between said broker(s) and said remote 
apparatus(es). 

As a consequence, the PETITE document is not relevant toward the invention as defined by 



-11- 

independent claim 1 of the present patent application. 

3. Non-relevance of the combination of IBM and PETITE documents 
Neither the IBM document nor the PETITE document is relevant towards the invention as 

claimed by independent claim 1 as described above. 

With neither the IBM document nor the PETITE document providing the inventive features of 

the independent claims, the combination of the PETITE and IBM documents does not disclose or 

suggest these features. 

As a consequence, the combination of the PETITE and IBM documents does not render the 
inventive content of independent claim 1 obvious to a person of ordinary skill in the art, and a 
moreover does not render the inventive content of dependent claims 4-9, 10 obvious (at least 
because these claims depend on claim 1). 

Accordingly, Applicant respectfully requests that the claim rejections under §§102 and 103 be 
withdrawn. 

Respectfully submitted, 

WESTMAN, CHAMPLIN & KELLY, P.A. 



By: /David D. Brush/ 
David D. Brush, Reg. No. 34,557 
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